Introduction… Hello, and welcome back to "From Another Perspective," my little ol' 3D column. This is a column dedicated to 3D topics including product reviews, how-to's, tips and tricks, general 3D babble, and eventually, learning the language of 3D. By reading this column regularly, I can assure you that you'll be ahead of the game when it comes to solving a particular problem with many of the 3D illustration and animation packages available. This column is written from an artist's perspective, not a scientist's. While there's bound to be some technical mumbo-jumbo, I promise to keep it to a minimum. This month we're going to talk about resolution, rendering, and how it applies to generating your 3D images. Note: Screen captures are at low-resolution so that each issue of Apple Wizards will be of an appropriately small size.   Rendering and Resolution… For those that don't know, your 3D project exists in essentially two different stages. Stage 1: There is the scene file which contains the "stage" on which you place your models, special effects, and lights. This scene file or project file is where you actually move and manipulate your "characters" about — shifting poses, positions, and using the time line to animate them (if that's your intent for the project). At this level, all scene elements are fully editable. If you decide to change a character's facial expression, the position of a prop or the color of a light, this is where you do it. Stage 2: Your project results in the final product, whether it's a still image or a moving animation. The process by which your scene file or project file becomes a viewable image is called rendering. The "Rendering Engine" is the heart and soul of any 3D application. The ability to take the scene file information and convert it to a picture or a movie is key. There are different methods of rendering, but we'll save a more in-depth look for another month. Rendering can be an extremely time- and memory-intensive process. The smaller you can render a scene, the better it is from a time point of view. Different 3D applications handle rendering in different ways. What I would encourage you to do when setting up a rendering in your 3D application is to start thinking in terms of resolution, not inches. Resolution, for our purposes here, is the number of pixels in an image. Now, given that a pixel is considerably smaller than an inch in most cases, it might seem a little confusing at first. But once you get the hang of it, determining the desired resolution is a snap. Given that you have access to some sort of image-manipulation software, such as Adobe Photoshop, re-sizing your image is simple once the actual pixel information has been rendered. The two images below illustrate two different resolutions. The left-hand one could be considered "low-resolution," and the right-hand one "high-resolution." Click on each image for further explanation.    Different 3D applications have different settings in their render window. For now, concern yourself with how many pixels the final image or movie will contain. Many applications, like Strata Studio Pro, LightWave, and Electric Image, allow you to key in the resolution of an image in a specific box. It doesn't really matter whether an image is 72 pixels per inch, or 400 pixels per inch, as long as you can view the final pixel count and determine whether you're rendering a "large enough" image or not.   Some Examples… Let me illustrate with a few examples. If I am rendering an illustration for a client that will be printed with traditional offset lithography (your typical commercial printer), I have established a few guidelines that give me a starting point for setting up my rendering. A typical offset press will use a 150-line screen for their film. This figures into our process directly because a rough rule of thumb is that your image resolution should be one and one half to two times your line screen. So, if I am using a 150-line screen, my resolution should be at least 300 pixels per inch in my final rendering. If my image is 8 inches wide by 10 inches tall (perhaps for a magazine page), my final resolution can be calculated: 8 in. x 300 ppi = 2400 pixels wide 10 in. x 300 ppi = 3000 pixels tall So in the rendering set up for my image, I'd type in 2,400 by 3,000. Clear as mud, right? It's really not hard at all, especially if you make use of the calculator Apple shoves into your Apple menu (something I use all the time). Another "higher-quality" example would be as follows: If that same commercial printer has the ability to "hold" a 175-line or even a 200-line screen on their printing presses, you may consider rendering even "higher resolution." For an image that will be produced using a 200 line screen, our resolution would be double that, or 400 pixels per inch. These numbers translate into our hypothetical 8 inches x 400 pixels per inch = 3,200, and 10 inches x 400 pixels per inch = 4,000 pixels. This formula would produce an extremely high-quality image. The more pixels you generate in the original rendering, the more information and detail they are capable of containing. A 200 line screen is then able to break that pixel detail into extremely fine line-screen detail and reproduce it on a printing press. That's all well and good, but what about rendering times and RAM? This is where the compromises begin. Not everyone has the resources to render an image at 3,200 x 4,000 pixels, nor is it always necessary. Many multi-media applications such as Macromedia Director would like an image no larger than 640 pixels by 480 pixels. Rendering time on this small image would be much, much faster. The best advice I can give on this subject is this: know what you will be using your rendered image for, and plan accordingly. A surprisingly common misconception involves the ability to re-sample (notice I didn't say re-size) your images up in Photoshop. Here's how that works: If you render a 640 x 480 image, and try to re-sample it up to "print-resolution," it will look awful. The reason is that your image is actually a grid of different colored pixels: it's comprised of a bunch of little squares. When you "re-sample" your image up, you add more pixels. Re-sampling up relies on the computer to create information by guessing pixel values based on surrounding pixel values. A program like Photoshop has three ways of accomplishing this: Nearest Neighbor, Bi-Linear and Bi-Cubic, the best of which is Bi-Cubic. When you re-sample an image up (or increase the number of pixels and thereby the file size), you create new pixel information based on color values of existing pixels. The image (immediately below) shows an example of having rendered a picture too small, then attempting to size it up in Photoshop using its best method, Bi-Cubic interpolation. As you can see, the information has been badly blurred and compromised.   The second image (below) shows the rendering created at the correct size and resolution. Each image seen here is 320 pixels by 240 pixels, at 72 pixels per inch. So you can see that what matters is not the resolution you enter in Photoshop, but the resolution you originally specify in the rendering window of the 3D program.   This is an important point, because it points out very well that you can't really cheat when it comes to rendering. If you need a high-res image, you need to render a high-res image. You can pay now, in the rendering information dialog (and with your time), or you can pay later (with poor image quality), but you can't create something from nothing. Although computers are getting faster all the time, high-resolution renderings take time. What used to take 10 hours to render on a 601 Power Mac could only take 2 hours on a new G3 PowerMac. The newer, faster computers make an enormous difference when it comes to rendering. Soon, though, you'll discover new effects and new ways of making even these new, incredibly fast machines fall to their knees and beg for just a little more time.   Minimizing Rendering Times… There are many things that you can do to minimize your rendering times. The first and most obvious is to get a faster computer. I'd recommend Apple's 333 MHz G3 (at least for now). The second is to load as much RAM into it as you can afford. RAM prices are dropping like stones, but it still costs money. Spend your money on as fast a processor as you can afford, then upgrade the RAM as you are able. These two factors are the two largest determinants to your rendering times. However, there are several other things that you can do to decrease your rendering times. 1. Watch your polygon count. Save polygons and geometry whenever and wherever you can. Each bit of information in your scene has to be calculated in the final rendering. Game makers are familiar with "polygon counts" and are well aware of the nasty effects when games try to put too many polygons on screen at the same time. 2. Use texture maps instead of models whenever you can. Clipping maps and bump maps can take the place of polygons in many instances. 3. Some applications use a memory-saving "instancing" feature, allowing you to create various "instances" of models, drawing on master geometry you need to create only once. This is extremely valuable because it allows the file size to remain small while working and it allows for faster renders. Master this feature in your application of choice. 4. When you anticipate a long rendering time, re-boot your machine with a special extension set that allows you to assign as much RAM as possible to your 3D application. The less overhead your system requires while rendering, the better. It also minimizes conflicts between extensions. 5. Many applications have a "spooling" feature, allowing you to use your hard disk as a storage area for partially rendered portions of the image. This can be much slower than relying solely on RAM, but it will get the job done in many cases. If you're going to do this, make sure you have a good-sized partition on your disk and that this portion is de-fragmented and optimized. This will minimize any problems. 6. Turn virtual memory off, or at least don't rely on virtual memory for your rendering. This is extremely important. If you only have 64 MB of real RAM in your machine, don't think by turning on VM and creating 128Mb you're fooling the rendering engine. Different engines have different ways of handling this, so consult your user manual for more information. By and large, however, 3D applications do not like to use virtual memory for their rendering chores. Personally, I choose to leave VM enabled, but to the recommended "1 MB over actual RAM" setting. This allows better memory management, but does not create "artificial" RAM. 7. Render only the resolution you need. I'm in the habit of rendering many times more than I need, "just in case." This of course takes more time, and I don't do it all the time. Given the fact that most of the work I do is for print, I know the end product will almost always be a high-resolution rendering. Additionally, I can always sample down (or reduce the file size of) a high-res image. Methods of working will vary, but I will create a series of low-resolution renderings to check for lighting balance, composition and other elements that will only show up in a rendering. When I hit the mark, I'll set the scene up for a high-res rendering and go to bed. When I wake up in the morning, my job is done!   Wrapping it Up… This has been a crash course in rendering and resolutions. I by no means covered all there is to cover, but hopefully have provided you with a little more information than you had before. If there are specific issues you wish me to cover, please email me. This column is for you, the 3D user, and I'm here to help. If you have any questions about anything relating to 3D, please feel free to send me an email at jbcrane@applewizards.com . Alternatively, feel free to look me up on the web at http://www.sandstudios.com/ . I'll do my best to answer your questions or at the very least to point you in the right direction. I write this column because I believe there are many out there who will find 3D an artistically enabling medium and have only a few basics to get beyond before the proverbial ball begins to roll. Until next month, Happy rendering!   John B. Crane jbcrane@applewizards.net     http://applewizards.net/